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CERTIFICATE REVOCATION SYSTEM 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application is a continuation of application Ser. No. 
08/559,533, filed Nov. 16, 1995, which is based on Provi- 
sional Application No. 60/006,038, filed on Oct. 24, 1995 
now U.S. Pat. No. 5,666,416. 

TECHNICAL FIELD 

The present invention relates generally to secure commu- 
nications and more particularly to schemes for certificate 
management. 

BACKGROUND OF THE INVENTION 

In many settings, it is necessary to certify certain data, as 
well as to revoke already issued certificates. For instance, in 
a Public-Key Infrastructure, (PKI) it is necessary to certify 
users' public keys. 

In a digital signature scheme, each user U chooses a 
signing key SK^ and a matching verification key, PK^. User 
U uses SKy to compute easily his digital signature of a 
message m, SIG^m), while anyone knowing that PK^ is 
U's public key can verify that SIG^m) is U's signature of 
m. Finding SIGj/m) without knowing SK^ is practically 
impossible. On the other hand, knowledge of PK^ does not 
give any practical advantage in computing SK^. For this 
reason, it is in U's interest to keep SK^ secret (so that only 
he can digitally sign for U) and to make PK^ as public as 
possible (so that everyone dealing with U can verify U's 
digital signatures). At the same time, in a world with 
millions of users, it is essential in the smooth flow of 
business and communications to be certain that PK y really 
is the legitimate key of user U. To this end, users' public 
keys are "certified." At the same time it is also necessary to 
revoke some of the already-issued certificates. 

CERTIFICATION AND REVOCATION OF PUBLIC 
KEYS. Typically, certificates for users* public keys are 
produced and revoked by certifying authorities called 
CA's. 1 A CA can be considered to be a trusted agent having 
an already certified (or universally known) public key. To 
certify that ?K V is U's public key, a CA typically digitally 
signs PK y together with (e.g., concatenating it with) U's 
name, a certificate serial number, the current date (i.e., the 
certification or issue date), and an expiration date. 2 The 
CA's signature of PK^ is then inserted in a Directory and/or 
given to U himself. 

*A complete public-key infrastructure may involved other authorities (e.g., 
PC As) who may also provide similar services (e.g., they may certify the 
public keys of their CA's). The present inventions can be easily applied to 
such other authorities. 

2 Be fore certifying U's public key, U is necessary to perform additional steps, 
such as properly identifying user U. The present invention, however, does not 
depend on these additional steps. 

Upon receiving the (alleged) digital signature of user U of 
a message M, SIG^M), a recipient R needs to obtain a 
certificate for PK^. (Indeed, SIG^M) may be a correct 
digital signature of M with respect to some public key PK^, 
but R has no guarantee that PK^ is indeed U's public key). 
Recipient R may obtain this certificate from the Directory, or 
from his own memory (if he has previously cached it), or 
from U himself. Having done this, R verifies (1) the cor- 
rectness of the CA's certificate for PK^ with respect to the 
CA's public key, and (2) the correctness of SIG^M) with 
respect to PKj/. (If the CA's public key is not universally 
known, or cached with R, then a certificate for this key too 
must be obtained.) 
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Certificate retrieval is thus possible, although not neces- 
sarily cheap. Unfortunately, however, this is not the only 
retrieval that R needs to do. Indeed, it is crucially important 
that R makes sure that the certificate for PK^ has not been 
5 revoked. This check, of course, may not be needed after the 
certificate's expiration date, but is needed during the cer- 
tificate's alleged lifetime. A user's certificate can be revoked 
for a variety of reasons, including key compromise and the 
fact that the user is no longer associated with a particular 

io CA ' 

To enable a recipient to establish whether a given certifi- 
cate has been revoked, it is known that each CA periodically 
issues and gives the Directory a Certificate Revocation List 
(CRL for short), in general containing an indication of all the 
(not yet expired) certificates originally issued by it. A CRL 

15 typically consists of the issuer's digital signature of (1) a 
header comprising the issuer's name (as well as the type of 
his signature algorithm), the current date, the date of the last 
update, and the date of the next update, together with (2) a 
complete list of revoked certificates (whose date has not yet 

20 expired), each with its serial number and revocation date. 
Since it is expected that a CA revokes many of her certifi- 
cates, a CRL is expected to be quite long. 

After performing some checks on the CA's CRL (e.g., 
checking the CA's digital signature, checking that the CRL 

25 has arrived at the expected time, that a certificate declared 
revoked in the previous CRL of that CA — and not yet 
expired — still is revoked in the current CRL, etc.), the 
Directory stores it under its CA name. 
When a user queries the Directory about the revocation of 

30 a certificate issued by a given CA, the Directory responds by 
sending to the user the latest CRL of that CA. The user can 
then check the CRL signature, the CRL dates (so as to 
receive a reasonable assurance that he is dealing with the 
latest one), and whether or not the certificate of interest to 

35 him belongs to it. 

While CRLs are quite effective in helping users estab- 
lishing which certificates are no longer deemed valid, they 
are also extremely expensive, because they tend to be very 
long and need to be transmitted very often. 

40 The National Institute of Standard and Technology has 
tasked the MITRE Corporation to study the organization and 
cost of a PKI for the Federal Government. This study 
estimates that CRLs constitute by far the largest entry in the 
Federal PKI's cost list. According to MITRE' s estimates/ 

45 assumptions, in the Federal PKI there are about three million 
users, each CA serves 30,000 users, 10% of the certificates 
are revoked, 3 CRLs are sent out bi-weekly, and, finally, the 
recipient of a digital signature requests certificate informa- 
tion 20% of the time. 4 The study envisages that each revoked 

50 certificate is specified in a CRL by means of about 9 bytes: 
20 bits of serial number and 48 bits of revocation date. Thus, 
in the Federal PKI, each CRL is expected to comprise 
thousands of certificate serial numbers and their revocation 
dates; the header, however, has a fixed length, consisting of 

55 just 51 bytes. 

3 5% because of key compromise and 5% because of change in affiliation with 
the organization connected to a given CA. 

"The remaining 80% of the time he will be dealing with public keys in his 
cache. 

At 2 cents per kilobyte, the impact of CRL transmission 
60 on the estimated yearly costs of running the Federal PKI is 
stunning: if each federal employee verifies 100 digital 
signatures per day on average, then the total PKI yearly costs 
are $10,848 Millions, of which 10,237 Millions are due to 
CRL transmission. If each employee is assumed to verify 
65 just 5 digital signatures a day on average, then the total PKI 
yearly costs are $732 Millions, of which 563 Millions are 
due to CRL transmission. 
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The MITRE study thus suggests that any effort should be 
made to find alternative and cheaper CRL designs. This is 
indeed the goal of the present invention. 

BRIEF SUMMARY OF THE INVENTION 

It is thus a primary object of the present invention to 
facilitate management of public key certificate revocation 
without providing users with lists of revoked certificates. 

It is another primary object of the invention to provide 
certificate revocation information to users of a public key 
communications system wherein a user can receive an 
individual piece of information about any public key cer- 
tificate instead of a large list of revoked certificates. 

It is still another object of the invention to reduce dra- 
matically the cost of managing public key certificates in part 
by reducing the size and number of transmissions by and 
among participants in the management scheme. 

It is a still further object of the invention to provide novel 
certificate revocation schemes wherein a certifying authority 
can provide a positive and explicit statement about the 
validity status of each not-yet-expired certificate. 

It is another object of the invention to allow certifying 
authorities to provide certificate validity information with- 
out requiring a trusted Directory. 

It is a further object of the invention to provide a certifi- 
cate management scheme wherein it is possible to prove that 
a given certificate was never issued or even existed. 

The foregoing has outlined some of the more pertinent 
objects of the present invention. These objects should be 
construed to be merely illustrative of some of the more 
prominent features and applications of the invention. Many 
other beneficial results can be attained by applying the 
disclosed invention in a different manner or modifying the 
invention as will be described. Accordingly, other objects 
and a fuller understanding of the invention may be had by 
referring to the following Detailed Description of the pre- 
ferred embodiment. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and the advantages thereof, reference should be made to 
the following Detailed Description taken in connection with 
the accompanying drawings in which: 

The FIGURE is a secure communications environment 
according to the invention including at least one user, one 
certifying authority and a directory wherein a certificate 
management scheme of the present invention is imple- 
mented. 

DETAILED DESCRIPTION AND PREFERRED 
EMBODIMENT 

By way of brief background, assume that each user U of 
a digital signature scheme has a signing key SKf/ and a 
matching verification key, PK^. User U uses SK^ to com- 
pute easily his digital signature of a message m, SIG^m), 
while anyone knowing that PK^ is U's public key can verify 
that SIG^m) is U's signature of m. PK^ must be the 
legitimate key of user U, and thus it is known to certify 
users* public keys are certified. This process is now 
described. 

Assume there are one or more certification authorities A, 
also known collectively as CA's. When U goes to A to have 
his public key PK^ certified, she identifies him, makes sure 
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that PKt/ is his public key, and then digitally signs the pair 
(U, PKy), indicating that PKy is U's legitimate public key. 
This signature, SIG^U^K^), is verifiable by anyone, 
because A*s public verification key, PK A , is assumed to be 
universally known or otherwise, for instance, properly cer- 
tified. The string SIG^UjPKy) constitutes a simple certifi- 
cate for PK^. Indeed, additional information can be included 
in PK[/s certificate. The present invention, as will be seen, 
works for any type of certificate for PKU as well as 
whenever certificates concern objects other than users* pub- 
lic keys. 

Such a certificate can be stored in a secure database or 
given to the user himself. Indeed, in order to enable a 
recipient of the signature SIG^m) to verify it, U may also 
given the recipient PK^ together with its certificate SIG A 
(UjPK^). In this way, the recipient may first verify that 
SIG^m) is a legitimate digital signature of m relative to the 
public key PK^ (no matter to whom this key may belong), 
and then check that PK^ is U*s legitimate public key by 
verifying its certificate (i.e., by verifying A*s digital signa- 
ture SIG(U,PK) with the help of the well-known public key 
of A). 

In the above system, U may be a buyer, the recipient a 
vendor, and m a payment for the purchase of a given good. 
The system is very convenient, but the possibility that public 
key certificates have been revoked must be addressed. If, for 
instance, U abuses of his digital signature power (e.g., he 
stops honoring the contracts or payments he signs), then his 
certificate SIG A (PK C/ ) must, somehow, be invalidated. This 
is the problem addressed by the present invention. 

The preferred embodiment of the new certification/ 
revocation system is now described. For simplicity of 
presentation, it is envisioned that a certificate revocation 
status is updated daily, although this is not a requirement of 
the present invention. According to the present invention, 
the CA has the responsibility of making and updating 
certificates. This is preferably accomplished in the following 
manner, although as will be seen other techniques may used 
as well. 

As seen in the FIGURE, the certifying authority CA sends 
to the Directory individual certificate revocation status infor- 
mation CRS, about each of its issued, but not-yet expired 
certificates C 1 . . . C*. The Directory sends CRS, to a 
requesting user who has inquired about certificate serial 
number "i" of that certifying authority. 

CA OPERATIONS (Making a Certificate.) A CA pro- 
duces the certificate of a user's public key by digitally 
signing together traditional quantities (e.g., the user's public 
key, the user name, the certificate serial number, the type of 
signature algorithm of the issuer, the certification or issue 
date, and the expiration date) plus two new quantities: a 
(preferably 100-bit) value Y— for "YES"— and a (preferably 
100-bit) value N — for "NO". These values are, at least with 
very high probability, unique to the certificate. 

The CA preferably generates Y and N by selecting two 
secret preferably 100-bit values, respectively Y 0 and 
N 0 , and then evaluating on them a given one-way 
function F 365 times (i.e., as many days in a year). 
Thus, YoY 365 =F 365 (Y 0 ) and N«N 365 =F 365 (N 0 ). 
The CA may select Y 0 and N 0 at random (in which case 
she must separately store them) or pseudo-randomly 
(e.g., she computes them from a secret master key — 
which she keeps in storage — and other inputs such as 
the string YES — respectively, NO, — the certificate 
serial number, and the issue date) in which case she can 
recompute them when needed rather than storing them 
at all times. 
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(Updating the CRS.) Daily (but not by way of limitation), The Directory checks that each newly received certificate 

a CA sends the Directory the following information: is we 11 -formed and properly signed. (In particular, it 

(a) Preferably, a digitally signed list of the serial numbers checks that the certification/issue date coincides with 
of all not-yet-expired certificates issued by her together lne current day.) 

with the current day; 5 The Directory checks that the latest list of not-yet-expired 

(b) Preferably, the new certificates made that day; and certificates of every CA is fine. (In particular it checks 
/x _ u . . j^-c* juu u that its date coincides with the current one, that the list 

(c) For each not.ya-exp.red certificate made by her, she .. and ^ nQ certificate dedared invaJid ^ 

sends a preferably l<X)-bn value computed as follows. ^\ ^ fa dec , ared yalid nQw) 

Assume that the current day is the ith date in some ^ r , ' ... 

standard reference (e.g., the ith day of the year, the ith 10 Fo , r every certificate, the Directory upon receiving its 

date after the issue date of the certificate, and so on). ' at6St 100 : bl1 u value V ' P" forms ' he fo " ow ' n 8 «*«*• 

fp , - r ( . r , ri i .• ♦ w Assume that the current day is i days after the cert ifi- 

rhen, if the certificate was valid and continues to be , , , J . _ J , _ , r 

i *-3 u j .t iv / u- u u „ -i cation date, and that the stored YES- and NO- values of 

valid, she sends the value , (which she may easily , .„ ' . , .„ . VT( 5 ^ 

compute by evaluating F 365-i times on input Y 0 ). If „ « rt lficate .° re > vt£ v ■ f v Vc« 

the certificate ceases to be valid that very day, she sends 15 Directory verifies whether F(V)=Y', if V is a YES 

the value (which she can easily compute starting 5lf ,, val » e ' and whe ' her F ^ . otherwise. 

- . x *«• I ^ * . s If aU was done properly, these values should, according to our convenuons, 

with N 0 ). If the certificate was vahd for the first j days ^ y .Y 3as . y and i n^n,^ respectively. 

after issuance, but has been invalid for the latest (Response to Users' Inquiries.) Assume, for simplicity, 

days, then preferably she sends the value N 365 _ (iV) 2Q that recipient users receive the certificates of their sending 

(which she can also easily compute from N 0 ). signers from the senders themselves. Thus, users make 

Note 1: Since there are one-way functions that are Directory queries just for determining the validity status of 

extremely easy to evaluate, updating a given CRS is very certificates already known to them, 

efficient, and at most 120 bits about it are preferably sent to When a user ij mqu i res a b ou t the status of a given 

the Directory; e.g., the certificate serial number (i.e., 20 bits) 25 certificate (e.g., by specifying its CA and its serial 

and a 100-bit (YES/NO) value. Alternatively, rather than number), the Directory retrieves and sends to U the 

sending a YES-value, a CA can sign the certificate's serial lalest YES-value and the latest NO-value of that cer- 

number together with the new date i and YES (if the tificate, 

certificate continues to be vahd). Also, rather than sending a ShouW v inquire abom a ^ number ^ does nQt 

NO-value if the certificate is no longer valid, the CA can 3Q correspond to any not-yet-expired certificate issued by 

directly sign that the certificate has been revoked together the CA thcn the Dircctory scnds tj the latcst , digitally 

with additional information (e.g., it may sign the certificate rf ^ serial . number usl of that CA or any other p r0 of 

serial number together with the string NO and the revocation mat lfae inquired . about certificate "does not exist." 

date, and/or additional information). In this case, such a Note 5: If a CRL-based system was adopted instead, when 

revocation signature need not be sent at every subsequent 35 a quefy abom a « non _ existing » certificate is made, it is 

CRS update. proposed herein that the Directory should provide U with a 

Note 2: Handling the Y/N values can be done in several df iul si ature that the certificate "does not 

ways; for instance, but without limitation, by using just one ex ° $t » 

or more values rather two YES- NO- values, or by using Note & ^ Direct is not tr usled very much, because 

trap-door functions, etc. Also, rather than just a one-way 4Q {{ cannQt „ make yalid » a revoked certificate> nor can it 

function, a CA C may use a one-way hash function H. For « make revoked » a valid one Assume the { ^ the date> 

instance, she may choose Y.-H^Cl), Y 2 -H(Y 1 ,C,2), and tha t a certificate has expired at some date j £i. Then, the 

and so on. If desired the hash function may have less or CA has ided SQ faf the Directory ^ at most j_ x 

additional inputs, such as the issue date of the certificate^ F . inverses of y 365 , that is, with the Y-values Y 365 , 

Note 3: The amount of information sent by a CA to the 45 y ^ if ^ Direct to make tbe certifi . 

Directory at each update is roughly twenty times as long as cate ^ vaHd a , dale ^ i( must inveft p (at least 0Qce) on 

a CRL. Indeed in a CRL update the CA .sends, on average y which [{ cannQt do because F is a on 

9 bytes (72 bits) for 10% of the certificates. For a CRS fo n ct£n? 

update, the CA preferably sends 120 bits for each certificate Assume nQW thal a certificate is valid at datc i, and the 

in Step (c), and just 20 bits per certificate in Step (a). The 5Q Directory wishes t0 co nv i nce a ^ that it has been revoked 

number of bits transmissed in Step (b) is roughly the same at a date lessef than Qf equaJ t0 L , Q 0fder tQ do SQj h must 

for both systems. invert F at least once on the certificate's N 365 value, which 

Note 4: Calling the Y, and N, respectively YES- and fa {{ cannot do because p is a one . way function 

NO-values, one may ensure that no YES-value coincides ^ CA does not ^ how t0 invcrt F in gcneraL She onJy ^ ows how to 

With a NO-value. In practice, however, this is unnecessary, 55 invert it on the Y, ( for i>0, because she chose Y 0 and N 0 , and constructed the 

because the probability Of this happening if the function F is YES and NO values by evaluating F, on the easy direction, starting from Y 0 

well-chosen is miniscule. (Indeed, for suitable choice of the t nd ^ ^ the ^ ^ invcrl F ° n u° n V by v either Storine aU intermediate 

. j , . .... . . m. 4 Y- values, or quickly recomputing them from Yq. 

parameters, it can be made much less than the probability Q0 ^ that F th 7 current date & is and lhat the 

that the digital signature algorithm of a CA is broken.) certificate ceased to be valid at date j<i, but the Directory 

DIRECTORY OPERATIONS 60 ^^sto convince a user that the certificate was actually 

revoked at a different date. Notice that, at the current date 

(Response to CRS Update). For every CA, the Directory k, the total number of "F-inversions" divulged by the CA for 

preferably stores all not-yet-expired certificates issued by a certificate revoked at time j<i, is still j Y-values (Y 365 , . . . , 

her, organized by serial number, and for each of them it also Y 365v ) and i-j N-values (i.e., N 365 , . . . , N 36S . ( ,.^). If received 

stores its latest YES-value and NO-value (or the revocation 65 at the current date i, this information specifies lhat the 

signature as described above). The Directory preferably revocation date is that is, 1 plus the number of divulged 

performs the following verification steps. Y-inversions. Indeed, if at current date i the Direc- 
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tory wished to pretend convincingly that the certificate was latter in any special way. Again, by contrast, in a CRL-based 

revoked at a date earlier than j, it should release at least one system, if a user queries — by error, malice, or other reason — 

less Y- inverse and at least one more N-inverse, which it the Directory about a serial number S that does not belong 

cannot do. Similarly, it at current date i the Directory wishes to any not-yet-expired certificate issued by a given CA, the 

to fake that the certificate was revoked after date i, it should 5 Directory cannot prove this to the user. Indeed, showing that 

produce at least one more Y- inverse, which it cannot do the latest CRL of that CA does not comprise S is not such 

either. 8 a proof. (It may actually be construed as proving that S's 

7 For instance, it may try to make trouble for someone who has accepted a certificate is valid.) Even giving the user all not-yet-expired 

signature relative to a public key that was valid at data d<j, by convincing certificates issued by CA is not such a proof: the user may 

someone else that the certificate of that public key was already revoked by t . . — . . . ... n 

datcd 3 J io suspect that the Directory is purposely withholding the 

^Fhis information, however, does not prove the revocation date if examined "right" certificate. Indeed, it is the CAtO be basically trusted 

at a later date, D>L Indeed, the revocation date could be any date d between in the system, the Directory service is trusted to a much 

j and j+(D-i). Assume therefore that a malicious person has received at date lesser extent 

D from the Directory Y 36W and ^ 2 6s^o^)- Then, he may evaluate F on the " \ _ t 

received YES-value so as to obtain the jth inverse of Y^, and may evaluate The transmission and COSt savings of the CRS approach 

F on the received NO-value so as to compute the (i-j)th F-inverse of N 36S . To 15 can n0 w be seen. Assume, for concreteness, that a certificate, 

prove what the revocation date is in a way that is verifiable at any point in ^ not reV0 ked, is valid for one year; that is, that the time 

tim£ see the discussion below. interval between its issue date and its expiration date is one 

For this reason it is not recommended that the CA signs , . y , . 

vtp » xt/"\ i c ™c a * f a ~a iv year. Since the savings of the CRS approach increase more 

the YES- and NO-values of every CRS update. Indeed, Y * . . * t . , . A t 

a m a *u' *u M ^-fl ♦ a i , r*\ than linearly with the total number of revoked certificates, 

and N are signed within the certificate, and only the CA may „ , , /. . . _ . t 

. P , L i \r J 20 and thus with the total number of certificates, let us assume 

easily invert F on them a few times. Thus any value V on , , « , t . . ' , t 

..... j- »• t? i a „. L* i« «;«,^ that each user has only one certificate, and thus that each CA 

which the one-way function F, evaluated at most 365 times, . „ ' 9 ' 

■uv . u u *ju4l^a issues 30,000 certificates a year, 

yields Y, must have been computed by the CA. - L1 . . . . . , , „ v , „ . „■ , » 

^ , i . i j* ii ^Presumably, instead, the typical user ofaPKI will have multiple certificates, 

The latest YES or NO-values may however be digitally bccausc hc ^ usc differcnt signing kcys for cach of his diffcrcnt ^ nctions: 

signed if desired. 25 private citizen, member of different organizations, sub-units, etc. 

Then, since 10% of the issued certificates are revoked 

USER OPERATIONS before their expiration date, we expect that each CRL 

Let Y and N be respectively the YES-value and the comprises 3,000 (-10% of 30,000) items. Therefore, disre- 

. - . Ve 1. ■ • „• • , t t sardine the 51 -byte header, the expected length of a CRL is 

NO-value of the certificate the inquiring user U is interested & ;iA mrt L ( ' n\ u / *u * • 01 ,aaa 

, , . . . . j & .u , , in some 27,000 (3,000 times 9) bytes; that is, some 214,000 

in, and let the current date be 1 days after the certificate s 30 v 7 J 

Though in some occasions these CRLs will be "pushed" 

If the Director sends him Y* and N' (the alleged latest by the CA , S directly tQ their users (like in the emergency 

YES- and NO-value of the certificate), preferably then user following to a major compromise of the system), they are 

U performs the following check. First he verifies that by ordmar ii y distributed in two modes: (1) biweekly from each 

evaluating F on Y' and N* he obtains, respectively, Y and N of the abom 100 CM t0 the Dir e Ct ory, and (2) daily from 

within a total of 1 F-evaluations. (As usual, we let F° denote some Directory agent t0 a requesting user. Of the two costs, 

the identity function.) m e second [ s absolutely greater. Even making the assump- 

Then, letting a and b be the number of F-evaluations tion that each user verifies only 5 digital signatures a day on 

needed to obtain, respectively, Y from Y* and N from ^ average (and that 20% of the time he experiences a cache 

N, he verifies that a+b«i. miss and queries the Directory), on average there will be 3 

If the Directory claims that the certificate "does not exist" Million daily CRL transmissions due to Mode 2, versus less 

by sending him the CA's signed list of serial numbers of than 40 (=100 CAs times 2 days/5 working days) daily 

not-yet-expired certificates, or an alternative proof, then U transmissions due to Mode 1. 

checks the CA's digital signatures, and that the serial The inventive certification/revocation system replaces 

number of interest to him does not appear in the list or each CRL with a CRS which is roughly twenty times as 

checks the alternative proof. long. Thus, Mode-1 costs jump from 40 CRL-transmissions 

per day to the equivalent of 800 CRL-transmissions per day. 

BENEFITS AND ANALYSIS (Assuming that CRL are updated bi-weekly while CRS 

The novel system enjoys three main advantages over the 50 daily ' Mode " 1 C0StS WOuld jump from 40 CRL-transmissions 

traditional CRL. First, it saves dramatically on bit transmis- P er da y t0 the equivalent of 2,000 CRL-transmissions per 

sions and costs. In this regard, recall that there are few da y-) However, each of the 3,000,000 Mode-2 costs will 

CRS/CRL updates. Indeed, they typically occur bi-weekly decrease from transmitting one CRL (i.e., 214,000 bits plus 

and are performed by the CAs which are few in numbers. By a di 8 ital signature) to transmitting just 120 bits. Therefore, 

contrast, there arc very many queries of users to the Direc- 55 even assumin S that CRS are updated daily, CRS are 1,000 

tory about certificate validity. Second, the inventive second times cheaper than CRLs. 

always provides a positive and explicit statement about the FURTHER ADDITIONAL VARIATIONS AND 

validity status of each not-yet-expired certificate. By MODIFICATIONS 
contrast, CRLs provided only indirect evidence; that is, the 

absence of a given serial number from a CRL was taken to go It should be appreciated that several variations of the 

mean that the corresponding certificate was still valid. above technique are possible, all within the scope of the 

Positive and explicit statements are much clear and ad van- invention. 

tageous from a legal point of view — e.g., from the point of u should be realized that the functionality of the inventive 

view of liability — and preferable to "double negatives." certificate revocation system can be changed as to suit 

(add to claims) Moreover, the inventive scheme always 65 different needs. In particular the CA needs not to perform 

allows a complete and satisfactory answer to any possible steps (a) or (b) during a CRS update (so as to focus only on 

query of a user to the Directory and without trusting the the revocation aspects of the invention). 
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Moreover, the preferred embodiment uses a one-way just public verification keys. Indeed, the invention provides 

function F and one YES- and one NO -value for the con- a system for enabling a signer to prolong the validity of any 

struction of a certificate. It should be realized the more than digital signature created by the signer. In particular, in other 

one one-way function can be used here. For instance, a contexts, the signer may extend the validity of her signature 

one-way function Fl may be used for the YES-values, and 5 without any Directory as an intermediate entity; indeed, she 

a one-way function F2 for the NO-values. Alternatively, a caD pro i ong the validity of a given signature by sending the 

one-way function F, may be used at level i, e.g., in the proper information directly to a recipient, 

preferred embodiment, for computing Y,. , from Y,. Also, » 4 . ,j . • . , . . , . . 

the one-way function used may depend on the certificate It should be appreciated that in the above embodiment a 

serial number or other variable information. All these in Pindar off-line scheme is .used I for signing, but that other 

approaches are within the scope of the invention. Indeed, by 30 off - hne schemes can be used ™ ihm the SC0 P e of thcmvcn- 

one-way function we mean any process F that can on some tion. In a known off-line signature scheme, as exemplified in 

legal input x easily generate a target y, while it is difficult U.S. Pat. No. 5,016,274, a signer makes use of two digital 

given a target y to generate an input x mapped by the process signature schemes: a first (traditional) scheme having PK as 

to y. In fact, F may be the process of verification of a the public verification key and SK as the relative secret key, 

signature scheme and x a signature of y. (Indeed, we shall 15 and a second scheme (which is preferably one-time) and has 

see that the preferred embodiment is a special type of digital public-verification key pk and secret verification key sk. The 

signature.) For consistency, however, we shall continue signer, in an off-line step, uses the first scheme (and thus SK) 

using the traditional terminology of one-way functions to produce a digital signature, 2, of the public key pk, 

assuming that only one of them is used. possibly with other data. In a subsequent step, the signer 

In the preferred embodiment the CA may continue to 20 mav (via sk) produce the digital signature, o, of a message 

provide F-inverses of the NO-value of a certificate that has with respect to pk using the second digital signature scheme, 

been revoked so as to give some indication of the revocation Such a ound si wre scheme can be useftll 5ecause 

date if desired. If determining the revocation date !S not ±t ^ component scheme may be suitably restricted 

necessary (or is handled by a separate method, e.g., by . *, - . „ . , ' ' . . 

presenting the CA's direct revocation signature including 25 and/( ? r P artlcularl y fast. For instance, the second scheme 

the revocation date or any other additional information), the ma y be one-time or capable of signing only certain messages 

CA may just provide the first F-inverse of N, and no other. and not others - Because of these restrictions, however, the 

(In this case, rather than setting N=N 365 =F 365 (N 0 ), it may be second can be ver y fast or r ^ mre ver y com P act 

more convenient choosing N=N 1 =F(N 0 ).) The Directory signatures. Speed, m general, is not an adequate compensa- 

wffl thus store (and provide requesting users with) the latest 30 tion for these limitations. However, these limitations can be 

YES-value as long as the certificate remains valid. When the overcome by continually changing the matching public and 

certificate is revoked, the Directory may forget the latest kevs (P k and sk ) for the second scheme and authen- 

YES-value and store instead the F-inverse of N (and/or the ticatin S the so-chosen public keys by digitally signing them 

direct revocation signature of the CA), which will be pro- b y means of a fast ™* fixed ( or at least less-variable) 

vided to requesting users as a proof of the revocation of the 35 traditional signature scheme. Although this first scheme 

certificate. Notice that still the Directory is not trusted very could be slower than the second scheme, it is used to sign pk 

much. Indeed, when requested at date i about the status of a ™ ^ oS-iinc step where performance, among other things, 

given certificate, it must respond either with the ith F-inverse ^ ^ GSS crucial. 

of Y, or with one inverse of N. This specific variation, Referring back to the present invention, assume for sim- 

however, while proving that a certificate has been revoked, 40 plicity that the preferred embodiment is implemented with a 

does not prove at all when it has been revoked. single additional certification value Y 365 (and that a CA 

However, one may dismiss the NO-values altogether, and directly signs that a certificate has been revoked when this 

yet prove the revocation date. For instance, a certificate may becomes the case). Then, Y 365 can be considered the public 

just have one 100-bit value Y«Y 365 . If the certificate remains key of a constrained signature scheme whose secret key is 

valid at date i, then the CA forwards the Directory the ith 45 Y o- Indeed, the CA signs Y 365 in a off-line step (when 

F-inverse of Y Else, the CA forwards a digital signature making a certificate) together with additional data (the full 

indicating that the certificate has been revoked, preferably certificate itself). In a subsequent step (i.e., during CRS 

also indicating additional data, such as the revocation date. update i) the CA uses the secret one-time key Y 0 in order to 

This direct signature may be stored by the Directory (so that si S n a constrained class of messages; that is, a value i 

the CA may no longer send anything else about a revoked 50 between 1 and 365, to signify that the certificate is valid up 

certificate if desired) and provided to requesting users as a to date i. 

proof of revocation. Such a direct signing step may require Notice that in this constrained scheme, given a signature 

more computation and may require more bits to transmit, but for i, anyone can compute a signature for j<i, but this is not 

it is conceptually simpler and provides a fixed and univer- a real forgery because any certificate valid up to date i is 

sally verifiable proof of revocation that is good at any date. 55 certainly valid up to date j (and indeed the value j was signed 

It should be appreciated that the information sent by the before signing i). Different one-time signature schemes 

CA in step (a) of a certificate update should be construed as could be used, in particular, to prevent someone who has not 

any information that enable one to verify whenever a given seen a previously signed message from re-signing it. 

serial number corresponds to some (issued an not-yet- The preferred embodiment may implement CRS with any 

expired) certificate. For instance, since there are 20 bits <so first and second signature scheme within the scope of the 

devoted to serial number information in the above example, invention and with more than one public keys for each 

and thus 2 20 (roughly a million) possible certificates issued scheme if desired. Again, other second signature schemes 

per CA, a CA may just digitally sign a 2 20 -bit string, where can be used to conveniently digitally sign arbitrary dates 

bit number i is 1 if there is a (not -yet-expired) certificate (and not just any date between 1 and 365) and the revocation 

issued by the CA whose serial number is i, and 0 otherwise. 6 5 date for revoked certificates (rather than having the CA 

It should also be recognized that the inventive system directly sign such revocation date within a revocation 

applies to the certification of arbitrary pieces of data, and not signature). 
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As for any off-line scheme, in this application there may set of instructions may be stored in another computer 

be a single signer for both the first and the second digital memory, for example, in a hard disk drive, or in a removable 

signature scheme as well as different signers for the two memory such as an optical disk (for eventual use in a CD 

schemes. Indeed, the CA(or any first entity) may generate R° M ) T or ^ disk (for eventual use in a floppy disk 

both the public and secret keys PK, SK, pk and sk, and then 5 <*nve). In addition, although the various methods described 

r , . , J . r v . . are conveniently implemented m a general purpose com- 

give sk to a second entity (e.g., the Directory), alternatively, selectively activated or reconfigured by software, one 

the second entity may come up with pk and sk, and ask the of orc iinary skill in the art would also recognize that such 

first entity to sign pk. Either way, the first entity can retain methods may be carried out in hardware, in firmware, or in 

the power of making a certificate, while empowering the more specialized apparatus constructed to perform the 

second entity to extend the validity of the certificate. By required method steps. 

giving proper one-time secret signing keys, the CA may Of course, digital signatures schemes and digital signa- 
ling the power of the second entity in an arbitrary way by tures should be construed broadly here so as to incorporate 
enabling it to sign certain messages and not others. For an V form of di ® { *} authentication or commitment. Actually, 
. .. .. , ... t . .„i„„ some of these authentication s need not be digital if desired, 
instance, it may hm the second entity to sign values as For mslance> the CA could us^ pen-written signatures when 
between 1 and 365 only. making a certificate, and rely on digital authentication/ 
Generalizing, the above-described off-line scheme may be commitment (e.g., the YES-value mechanism) for extending 
construed as one in which a first entity digitally signs, using the certificate validity. 

a first digital signature scheme, the public key of a second As used herein, it should be appreciated that a "user," a 

digital second signature scheme whose secret key is known 20 "certifying authority" and/or a "directory" may be a 

to a second entity, where the second digital signature scheme computer, a person or entity operating a computer or other 

is restricted so as to be able to sign certain predetermined workstation, or a multiplicity of such persons or entities, 

messages, and not others, to thereby enable the second entity Also, "certificate;' should be broadly construed as the digital 

to sign solely predetermined messages. In the above 25 s Jf a ,f K e ° f a S iven Pf e f d f* A certifying authority 

& , , , . , t * i « should be broadly construed as the signer of this piece of 

examples, the predetermined messages are the values 1 ^ ^ problem of « revoking a certificate » snould be 

through 365. Thus, only the CA can generate a new broadly construed as well, as taking away or invalidating the 

certificate, but he may leave to the Directory the power of validity of or commitment to the signature. In contrast, the 

lengthening the validity of the certificates she creates on a inventive methods should likewise be construed to provide 

daily basis for, for example, a maximum of a year. This 30 the advantage of lengthening or extending the validity of a 

technique is most useful when the second entity is not totally signature, even after a prescribed expiration date. A user 

trusted at least by the first entity and therefore the messages should be construed to include any entity that is interested in 

it can sign are restricted in a way comfortable to the first verifying whether a given certificate is valid at a certain date, 

entity. It can also be arranged that only the second entity is 35 A directory should be construed like any entity that may 

responsible for the messages it authenticates relative to pk; assist certifying authorities and users in the above tasks 

alternatively, because the first entity has signed pk (and "*™8 now described my invention with respect to the 

, , . . * ■ A preferred embodiments, the following is what I now claim, 

because the second entity can only sign certain predeter- r what is claimed is- 

mined messages relative to pk) the first entity takes respon- j A method of generating a certificate for data, compris- 

sibility for the messages signed by the second entity relative 40 m g tne s t e ps of: 

to pk. This scheme is very useful if the first entity desires to ( a ) generating a final value by iterating a one-way func- 

be represented by many agents (e.g., many second entities) tj on on a secret first value; 

and thus be relieved of the burden of signing certain pre- ( D ) generating certificate information that includes the 

determined messages, e.g., over some period of time or due 45 data and the final value; and 

to some contingency. (c) generating the certificate by digitally signing the 

The foregoing has outlined some of the more pertinent certificate information, 

objects and details of a preferred embodiment of the present 2, A method according to claim 1, wherein the data 

invention. These objects and details should be construed to includes a public key of a public-key cryptosystem. 

be merely illustrative of some of the more prominent fea- 50 3. A method according to claim 1, wherein a first entity 

tures and applications of the invention. Many other benefi- generates the final value and a second entity digitally signs 

cial results can be attained by applying the disclosed inven- the certificate information. 

tion in a different manner or modifying the invention as will 4. A method according to claim 3, wherein the second 

be described. Those skilled in the art will recognize that the entity is a CA. 

invention can be practiced, with modification, in other and 55 5. A method according to claim 1, wherein the one-way 

different certification methods and schemes within the spirit function is a hash function. 

and scope of the invention. 6. A method according to claim 1, further comprising the 

Those of ordinary skill in the art will appreciate that any ste P 

of the Users, CA and the Directory may be or have associ- (d) providing at least one additional value as an input to 

ated therewith a computer or workstation with suitable 60 at least one iteration of the one-way function, 

processing and storage capability to carry out the steps of the 7. A method according to claim 1, further comprising the 

inventive methods. Each such computer or workstation has step of: 

a suitable processor, known input/output devices and control (d) providing at least one additional value as an input to 

programs. One of the preferred implementations of the every iteration of the one-way function, 

various routines disclosed above is as a set of instructions in 65 8. A method of proving that previously certified informa- 

a code module resident in the random access memory of a lion is valid at each date in a sequence of dates, comprising 

computer or workstation. Until required by the computer, the the steps of: 
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(a) at each of the sequence of dates, determining whether 
the previously certified information is valid; and 

(b) if the certified information is valid at a date within the 
sequence of dates, producing a string unique to the 
certified information authenticating that the previously 
certified information is valid at the date. 

9. A method according to claim 8, wherein the string is a 
digital signature. 

10. A method according to claim 9, wherein the digital 
signature is off-line. 

11. A method according to claim 9, wherein a certifying 
authority produces the digital signature. 

12. A method of authenticating that each member of a 
subset of certifies that bind given keys to given users is valid 
at a given date, comprisign the steps of: 
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(a) determining each of the members of the subset that are 
valid at a given date specific to the member; and 

(b) for each member of the subset that is determined to be 
valid, authenticating that the member is valid at the 
given date by producing a string unique to the member. 

13. A method according to claim 12, wherein the string is 
a digital signature. 
3 14. A method according to claim 13, wherein the digital 
signature is off-line. 

15. A method according to claim 13, wherein a certifying 
authority produces the digital signature. 

***** 



05/18/2004, EAST Version: 1.4.1 



